1. Field of the invention
The invention relates to mobile communication networks and mobile terminal. Particularly, the invention relates to a method for the performing of handovers in a communication system.
2. Description of the Related Art
Currently mobility is provided for nodes employing Internet Protocol (IP) connectivity on protocol layers below the network layer. This means that the mobility is hidden from the network layer, that is, the IP layer, and that the node IP address remains the same throughout a continuous communication session. The maintaining of the connection and the relaying of data to the current location of the node is left for dedicated mobile networks such as the General Packet Radio Service (GPRS) core network. However, it would be beneficial to be able to rely on IP routing in the relaying of packet data to the current location of the node, which provides a number of benefits, for example, reduced investments in network equipment and simplified system maintenance. The support for mobility in the network layer requires the changing of IP address when the network access point is changed. This introduces the problem of maintaining an ongoing communications session with a peer node, which is not aware of the changes in the IP address.
One method of dealing with this problem is provided by Mobile IP, which is defined by Internet Engineering Task Force (IETF). In Mobile IP a mobile node is accessed via a home agent, which provides a permanent address for the mobile node. Before a route optimization procedure is performed, at least all terminating packets are routed via the home agent. The mobile node obtains a care-of address from its current network and registers the care-of address to the home agent. The home agent routes the packets to the care-of address using IP tunneling. The problem with mobile IP is that it introduces a significant delay to the packet stream. Further problems are related to firewalls and network security, which in effect mandate that outgoing packets should also be tunneled to the home agent before they may be routed independently. Due to these reasons, mobile IP is considered not to provide an ultimate solution for terminal portability. There also exists the possibility to deal with the problem on the transport layer, for example, on the Transmission Control Protocol (TCP) layer by splitting a transport layer connection to two parts and to have a transport layer proxy. Another transport layer protocol is the Stream Control Transmission Protocol (SCTP), the benefit of which is the support for multi-homing, namely, the support of multiple concurrent IP addresses for a communication party relating to a single transport layer association. In the case of failure to communicate with one of the IP address, a second address may be attempted.
Reference is now made to FIG. 1A, which is a block diagram illustrating the structure of a Stream Control Transmission Protocol (SCTP) packet in prior art. The SCTP is described in detail in Internet Engineering Task Force (IETF) document RFC 2960. SCTP performs tasks of a transport layer in the Open System Interconnection (OSI) model of data communications. In FIG. 1A there is show an SCTP packet, which comprises a common header 100 and a number of chunks. The chunks are distinct SCTP protocol messages. There may be N different chunks in a given packet, where the letter N stands for an arbitrary integer. The number of chunks within a given packet is only limited by the Maximum Transmission Unit (MTU) size on the IP layer. The SCTP specification also governs the allowed combinations of SCTP chunks in a single packet. For example, an initiation chunk INIT may not be bundled together with other chunks to an IP packet. In FIG. 1A there are shown two chunks, namely a chunk 110 and a chunk 120. The possible intervening chunks are not shown. The common header shared by all chunks in a packet consists of a source port number 101, a destination port number 102, a verification tag 103 and a checksum 104. The source and destination addresses are carried in the IP layer packet header. Verification tag 103 is used to associate an SCTP chunk with a given SCTP association. Verification tag 103 must remain the same during the SCTP association as soon as received in an INIT or INIT ACK chunk for the peer. Associated with chunk 110 there are shown the chunk specific fields that are present in every chunk. There is a chunk type field 111, which identifies the SCTP message, that is, the chunk. There are also chunk flags 112, a chunk length 113, and a chunk value 114. Chunk value 114 comprises the chunk type specific fields.
Reference is now made to FIG. 1B, which is a block diagram illustrating the structure of a Stream Control Transmission Protocol (SCTP) DATA chunk in prior art. The DATA chunk is used to carry upper layer protocol data to the peer. It is illustrated as an example of the structure in an SCTP protocol message, that is, a chunk. The DATA chunk comprises a chunk type 131, chunk flags 132, a chunk length 133, a Transmission Sequence Number (TSN) 134, a stream identifier 135, a stream sequence number 136, a payload protocol identifier 137 and user data 138. In the case of the DATA chunk the chunk type has the value 0. Chunk flags 132 comprise a flag indicating an unordered DATA chunk and chunk fragment end and beginning flags. The end and beginning flags are used in the adaptation to the IP layer MTU size if the DATA chunk does not fit to a single IP packet. The transmission sequence number indicates number for the DATA chunk and it is used in the detection of duplicate or missing DATA chunks. It should be noted that SCTP supports selective acknowledging with a SACK chunk, which allows a certain number of gaps in the TSNs received and thus avoids the need for the resending of all pending DATA chunks in the case of isolated lost DATA chunks. Due to the fact that SCTP supports multiple parallel streams, stream identifier 135 is used to identify the stream to which the DATA chunk is associated. Stream sequence number 136 represents the stream sequence number for the following user data within the stream specified with stream identifier 135. Payload protocol identifier 137 is used to identify the upper layer protocol, the message of which is carried in user data 138. An extension of SCTP supports the adding and removing of peer IP addresses during an existing SCTP association with Address Configuration Change (ASCONF) chunks.
However, a problem associated with prior art transport protocols is that they do not provide support for cases where both transport layer connection or association parties are mobile nodes. It should be noted that the problem is not specific to TCP or SCTP, but similar problems are present in any transport layer protocols.